I love the sound of this, but I don't feel like I know exactly what use cases you are trying to enable or aiming to do. Can you give a bit more detail on what kind of things you aim to do? Is the (shiny future) goal to rewrite PartialEq and friends as some kind of fn that is written reflectively instead? Would it be generic over a data structure? Is the expectation that we could 'specialize" it to the type (and get efficiency)? Are you not sure yet, but you know the building block is X?

If you could give a high-level sketch of what these APIs might look like, that'd be great, and bonus points if you can sketch the whole set of connections you eventually imagine.

I don't want this goal to have everything designed up front or anything, I just want to understand the big pieces in your head.

I gave some more details, but

Are you not sure yet, but you know the building block is X?

is a very strong motivation here 😆 I have been wanting some sort of const eval that does type stuff for a long time, and consuming types is much easier than producing new types (which I want to do at some point), so why not start there

I think there are interesting! I'm having a bit of trouble connecting them to the write-up above, perhaps because I don't quite get what alternatives you are weighing against.

This does not connect to the write-up above because it is a design axiom for how to write reflection, not why to do reflection. I link to more details below, but TLDR: I do not think uwuflection is the right way forward, as it is a very declarative/functional approach compared to the usual imperative const eval approach we use.

@tmandry would need to assign a champion here

ah, some of the details I wanted are here, though I had some trouble understanding some of these questions. e.g., "why not go full zig-style comptime" in particular felt like a bit of a nonsequitor.

maybe because I don't know zig that well

How will privacy be enforced? E.g. for serialization, it is important that private fields can be accessed in serde code. At the moment the privacy boundary is natural as the proc-macro generated code is inside the same module as the struct etc. Would it be possible to give serde access to some private fields, but not other random reflection code? Or is the idea that anything exposed to reflection should be the equivalent of a pub struct with pub fields, and any e.g. deserialisation validation would need to be pushed into a later conversion to a different type? Perhaps we'll need some #[reflect] macro to annotate some fields, though that would open a can of worms of which modifiers from serde and elsewhere to support.

I think we should just punt on this for now and see how far we can get with just public fields. If it turns out you want to be able to create values only via an API that does some sanity checks maybe we'll be able to figure something out, but we'll leave it out of an MVP (I give it a week of the first release of someone sticking data into doc comments on the type that guide their serializer to invoking methods instead of accessing fields 😆 )

Starting with just "everything must be pub" for the MVP sounds good to me, though it will be useful to keep track of since validation at deserialisation time is a killer feature of serde. Though ... if reflection can inspect (arbitrary) attributes on public fields, then maybe #[reflect(serde::serde(serialize_with = "path"))] could work where reflect would just provide the outer attribute but not parse anything inside (but e.g. serde could then act based on that)